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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respect 
of ETSI standards", which is available free of charge from the ETSI Secretariat. Latest updates are available on the 
ETSI Web server (http://www.etsi.org/ipr). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in SR 000 314 (or the updates on the ETSI Web server) 
which are, or may be, or may become, essential to the present document. 



Foreword 



This Technical Specification (TS) has been produced by the Special Mobile Group (SMG). 

In analogy with CCITT Recommendations 1.130, the following three level structure is used to describe the 
telecommunications services as provided by European public telecommunications operators: 

Stage 1 is an overall service description, from the service subscriber's and user's standpoint; 

Stage 2 identifies the functional capabilities and information flows needed to support the service described 

in stage 1 ; and 

Stage 3 defines the signalling system protocols and switching functions needed to implement the service 

described in stage 1. 

The present document details the stage 2 aspects (functional description) and some stage 3 aspects for the support of a 
Mobile Station Application Execution Environment (MExE). 

The contents of the present document are subject to continuing work within SMG and may change following formal 
SMG approval. Should SMG modify the contents of the present document it will then be re-released by ETSI with an 
identifying change of release date and an increase in version number as follows: 

Version 7.x.y 

where: 

7 indicates GSM release 1998 

X the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, updates, 
etc. 

y the third digit is incremented when editorial only changes have been incorporated in the specification. 
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1 Scope 



The present document defines the stage 2 and stage 3 description of the Mobile Station AppUcation Execution 
Environment (MExE). Stage 2 identifies the functional capabilities and information flows needed to support the service 
described in stage 1 . 

The present document includes information applicable to network operators, service providers and terminal, switch and 
database manufacturers. 

The present document contains the core functions for a Mobile Station Application Execution Environment (MExE) 
which are sufficient to provide a complete service. 

MExE uses a number of technologies to realise the requirements of the stage 1 description (GSM 02.57). The present 
document describes how the service requirements are realised with the selected technologies. The present document is 
devised into sections each covering the aspects relating to particular MExE technologies, it is intended that the present 
document will evolve along with the MExE technologies. A generic section of the present document covers areas of 
MExE common to all technologies. 
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3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply. 

administrator: The administrator of the MExE MS is the entity which has the control of the third party trusted domain, 
and all resources associated with the domain. The administrator of the device could be the user, the operator, the service 
provider, or a third party as designated by the owner of the device. 

certificate: An entity that contains the issuer's public key, identification of the issuer, identification of the signer, and 
possibly other relevant information. Also, a certificate contains a signed hash of the contents. The signer can be a 3rd. 
party other than the issuer. 

fine grain: Refers to the capabilities of the Java security system to allow applications, sections of code or Java classes to 
be assigned permissions to perform a specific set of privileged operations. The smallest programming element that can 
be given permission attributes is a Java class [19] 

key pair: Key pairs are matching private and public keys. If a block of data is encrypted using the private key, the 
public key from the pair can be used to decrypt it. The private key is never divulged to any other party, but the public 
key is available, e.g. in a certificate. 
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personal certificate: This is a certificate loaded by the user or a user application which is limited to the application that 
it is intended for, and is not a MExE Certificate. E.g. an e-mail application could load certificates for its usage. Personal 
certificates are out of scope for MExE. 

phonebook: A phonebook is a dataset of personal or entity attributes. The simplest form is a set of name-number pairs 
as supported by GSM SIMs. 

MExE: MExE (Mobile station application Execution Environment) is defined in detail in this document, but the scope 
of MExE does not include the operating system, or the manufacturer's execution environment. 

MExE certificate: This is a certificate used in the realisation of MExE security domains. A MExE Certificate can be 
used to verify downloaded MExE executables. Use of the word "certificate" in this document implies a MExE 
certificate. Other varieties of certificate will be explicitly qualified as a e.g. "Personal Certificate". 

MExE executable: An executable is an applet, application, or executable content, which conforms to the MExE 
specification and may execute on the ME. 

MExE Java VM: This is a standard Java virtual machine used to execute MExE Java applets and applications 

MExE native library: This is a downloaded native library that can be accessed by MExE executables 

MExE-SIM: A SIM that is capable of storing a security certificate that is accessible using standard mechanisms.. 

owner: An owner of the MExE MS. An owner could be a user, operator (e.g. where the MS is obtained as part of a 
subscription and the cost of the MS is subsidised), service provider, or a third party (e.g. the MS is owned by the user's 
company and this company wishes to control how the MS is used) 

power up event: An abstract event that occurs when the MExE MS is cold started (i.e. switched on). 

sandbox: A sandbox is a safe area to run Java code. Untrusted Java code executing in a sandbox has access to only 
certain resources [18] 

service: A service (which may consist of an application or applet, and its related content) is a set of functions offered to 
a user by an organisation, and may be performed on the MExE MS and/or remotely 

service name: An identifier associated with a service, which could be a string, a fully qualified Java class name, a 
unique URI or other identifier. 

signature: "Signing" is the process of encrypting a hash of the data using a private key. If the signature can be 
decrypted using the public key, then the signature is valid. 

signed JAR file: Archives of Java classes or data that contain signatures that also include a way to identify the signer in 
the manifest. (The Manifest contains a file which has attributes defined in it.) 

user: The user of the MExE MS 

Further definitions specific to MExE are in GSM given in 02.57 (MExE stage 1) [2]. 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

API Application Programming Interface 

CA Certification Authority 

CC/PP Composite Capability/Preference Profiles 

CGI Common Gateway Interface 

CCM Certificate Configuration Message 

CP -Admin Certificate Present (in the MExE SIM) - Administrator 

CP-TTP Certificate Present (in the MExE SIM) - Trusted Third Party 

DHCP Dynamic Host Configuration Protocol 

GSM Global System for Mobile Communication 

HTTP HyperText Transfer Protocol 

HTTPS HyperText Transport Protocol Secure (https is http/1.1 over SSL, i.e. port 443) 
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IP Internet Protocol 

JNDI Java Naming Directory Interface 

JTAPI Java Telephony Application Programming Interface 

JAR file Java Archive File 

MSB MExE Service Environment 

OCF OpenCard Framework 

RDF Resource Description Format 

RFC Request For Comments 

SAP Service Access Point 

SMS Short Message Service 

TLS Transport Layer Security 

TTP Trusted Third Party 

UDP User Datagram Protocol 

UI User Interface 

URL Uniform Resource Locator 

URI Uniform Resource Identifier 

USSD Unstructured Supplementary Service Data 

WAE Wireless Application Environment 

WAP Wireless Application Protocol 

WDP Wireless Datagram Protocol 

WSP Wireless Session Protocol 

WTA Wireless Telephony Applications 

WTAJ Wireless Telephony Applications Interface 

WTLS Wireless Transport Layer Security 

WTP Wireless Transaction Protocol 

WWW World Wide Web 

Further abbreviations are given in GSM 02.57 (MExE stage 1) [2] and GSM 0L04 [1]. 



Generic MExE aspects 



This section defines the common aspects of all MExE compliant devices, independent of MExE technology. 

Considering the wide and diverse range of current and future technology and devices that (will) use wireless 
communication and provide services based thereon a one-size-fits-all approach is unrealistic. Instead this TS categorises 
devices by giving them different MExE classmarks. In this specification two MExE classmarks are defined: 

• MExE classmark 1 - based on WAP (Wireless Application Protocol) [6] - requires limited input and output 
facilities (e.g. as simple as a 3 lines by 15 characters display and a numeric keypad) on the client side, and is 
designed to provide quick and cheap information access even over narrow and slow data connections. 

• MExE classmark 2 - based on Personal-Java [3] - provides and utilises a run-time system requiring more 
processing, storage, display and network resources, but supports more powerful applications and more flexible 
MMIs. MExE Classmark 2 also includes support for MExE classmark 1 applications (via the WML browser.) 

Future classmarks may require other Java-packages, APIs, and/or support of other features such as speech-recognition, 
video-I/O with online (de)-compression, minimal storage requirements, high-speed local communication, etc. but these 
are subject to future standardisation efforts. 

Content negotiation allows for flexible choice of formats available from a server or adaptation of a service to the actual 
classmark of a specific client device. 

Bi-directional capability negotiation between the MExE Service Environment and MExE device (including MExE 
classmark), supports the transfer of capabilities between the client and the server. 
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4.1 MExE classmark 1 (WAP environment) 

The WAP forum has proposed designs for both the transport protocols on the wireless leg of the end-to-end connection 
(based on the Wireless Datagram Protocol (WDP), the Wireless Transaction Protocol (WTP), Wireless Transport Layer 
Security (WTLS) and Wireless Session Protocol (WSP)), as well as the client-side application environment, which 
revolves around a Wireless Markup Language (WML) browser supporting a Wireless Markup Language Script 
(WMLScript). 

4.2 MExE classmark 2 (Personal Java environment) 

This classmark characterises Java enabled devices with telephony specific extensions. 

4.3 High level architecture 

The following architectural model shows how a GSM network uses standardised transport mechanisms to transfer MExE 
services between the MS and the MExE service environment, or to support the interaction between two MSs executing a 
MExE service. 

The MExE service environment could, as shown in figure 1, consist of several service nodes each providing MExE 
services that can be transferred to the MS using standard Internet protocols. The MExE service environment may also 
include a proxy server to translate content defined in standard Internet protocols into their wireless optimised 
derivatives. 

For the versatile support of MExE services, the network shall provide the MS with access to a range of GSM bearer 
services on the radio interface to support application control and transfer from the MExE service environment. 
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4.4 Capability and content negotiation 

Interaction between the MExE MS and the MSE shall be supported by the use of the hypertext transfer protocol 
HTTP/1.1 [9], or an HTTP/1.1 derived protocol (e.g. WSP as defined in Wireless Application Protocol [6]). 
Communication between the MExE MS and the MSE supports:- 

• Capabihty negotiation 

The MExE MS connects to the MSE by using HTTP/1.1 or an HTTP/1.1 derived protocol. Capability negotiation 
between the MExE MS and the MSE only takes place for the first time after the MExE MS has connected to the 
MSE, and the MSE is informed about the MExE MS. Without this first initial contact from the MExE MS, the MSE 
has no knowledge of the MExE MS, and thereafter the MSE may connect to the MExE MS by using HTTP/1. 1 or an 
HTTP/1 . 1 derived protocol. 

Capability negotiation represents the mechanism by which the MExE MS and the MSE interact to inform each other 
of the specific mechanisms, capabilities and support which each is able to provide or support within the scope of a 
MExE service interaction. The capability negotiation normally takes place prior to any content transfer between the 
two entities. 

Capability negotiation is used by the MSE to request the MS' MExE capabilities, to which a response may be 
returned by the MExE MS. Information is normally requested by the MSE and supplied by the MExE MS, however 
the MExE MS may also be informed by the MSE of its current view of the MExE MS's capabilities. The MExE MS 
may also spontaneously inform the MSE of its capabilities without initially being requested to send them (i.e. 
following a change in MExE support, such as removal of MExE MS from a docking station with its keyboard, mouse 
and monitor). The characteristics which may be requested and transferred between the MExE MS and the MSE 
during the capability negotiation are identified in subclause 4.4. 1 Capability negotiation characteristics. 

• Content negotiation 

Content negotiation represents the means by which the MExE MS and the MSE inform each other of the requested 
and available form of content. If needed, the content negotiation may take place following capability negotiation 
between the two. The methods for content negotiation are the basic HTTP/1 . 1 . or WSP methods explained in [9] and 
[6]. 

Content negotiation is used to select the best representation of an entity when there are multiple representations of 
the entity available from the MSE. The entity (e.g. a service, an image, etc) is located behind a URI, and the 
application in the MExE MS connects to the URI by using HTTP/1.1 or an HTTP/1.1 derived protocol. The best 
representation of an entity can be decided by the server (server-driven negotiation) or by the client application 
(agent-driven negotiation). 

Both the capability and the content negotiation has the same purpose: to optimise the content according to client's 
capabilities. The term "content negotiation" has been used e.g. in the HTTP specification and the HTTP/1.1, and the 
WSP contain headers to perform the content negotiation. However, the capability negotiation in MExE aims at 
extending the basic HTTP and WSP methods for content negotiation. MExE terminal is free to use both the existing 
HTTP/WSP content negotiation methods and the new MExE capability negotiation methods. 

The content negotiation transferred between the MExE MS and the MSE is identified in subclause 4.4.2 Client 
Capability Report onwards. 



4.4.1 Capability negotiation characteristics 



Method for capability negotiation is based on the CC/PP specification made by W3C, [16]. The properties and the actual 
schema is based on the WAP UAProf group specification [17]. The Composite Capability/ Preferences Profiles 
framework is intended to provide an efficient mechanism for enabling enhanced content and service negotiation through 
a standardised format for user agent profiles. The use of Resource Description Framework (RDF) in CC/PP allows for 
interoperable encoding of the profile metadata in XML and supports multiple vocabularies to provide for future 
extensibility. WAP UAProf is based on the CC/PP framework. The purpose of the UAProf is to specify 

• an RDF based schema and vocabulary for CC/PP in the context of WAP UAProf that includes the class definitions 
and semantics of attributes described in a user agent profile, and 
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• guidelines for schema extensibility to support a composite profile that enables future additions to the vocabulary 
and schema. 

Not all capabilities have to be reported in the request to the server but instead, the client may point to an URL where the 
server may fetch the properties. 

The generic set of capabilities which may be negotiated between the client and the server consists of the subsequently 
identified properties in the UAProf schema, [17]. A MExE terminal shall support (but not be limited to) the following 
properties in the UAProf schema for capability negotiation: :- 

MexeClassmark 

MexeSpec 

Vendor 

Model 

Screensize 

Screens izeChar 

ColorCapable 

AudioInputEncoder 

VideoInputEncoder 

PointingResolution 

Language 

LocationEncoding 

TerminalLocation 

Keyboard 

SoftwareVersion 

SupportedBearers 

It is not required that a MExE terminal shall send all the above properties together when sending a request, however it 
shall be possible for the MExE terminal to send one or more of the above properties if subsequently requested by the 
server, with user permission. 

Generally, the combination of user profile and ME logic will determine the information sent in the capability negotiation 
from the MExE device to the MExE Service Environment. As an example, for the support of location information the 
user's profile controls if and when location information may be sent to the MExE Service Environment (e.g. never sent, 
always sent, only after user confirmation). 

The capability negotiation process shall be used by the client to permit transfer of capabilities from the client to the 
server. By transferring its capabilities, the client will support efficient use of resources both over the radio interface as 
well as in the client or server. Capability negotiation shall be performed prior to transfer over the radio interface to 
verify as far as possible the ability of the client to support any services to be downloaded. 

In order to transfer the capability information between the MExE MS and the MSE, CC/PP method is used with the 
schema defined in the WAP UAProf working group. 

4.4.2 CC/PP over WSP (classmarkl ) 

In classmark 1 the CC/PP is carried over by using CC/PP over WSP, [17]. 
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4.4.3 CC/PP over HTTP (classmark2) 

In classmark 2 the CC/PP is carried over by using CC/PP over HTTP, [15] or CC/PP over WSP, [17]. 

4.4.4 Client content capability report 

The client may perform content negotiation capabilities to the server by using appropriate HTTP/1.1 or WSP request 
headers. The following methods are available for content negotiation: 

• Client software (product): User-Agent header 

• MIME media types: Accept header 

• Character set: Accept-Charset header 

• Content encoding: Accept -Encoding header 

• Language: Accept -Language header 

There is no need for MExE to specify any tokens for content negotiation, as these headers are already defined in HTTP 
and WSP. The formats for these headers are specified in [9] and [6]. 

Example: 

The following HTTP request reports that the name of client software is "GSM-Phone" version "1.0". The client accepts 
both compiled WML and compiled WMLScript, and supports both the English and Swedish as languages. 

GET / HTTP/ 1.1 

Host; www.company.com 

User-Agent: GSM-Phone/1 . 

Accept: application/x-wap . wmlc, application/x-wap. wmlscriptc 

Accept-Language : en, sv 

The basic format of the User-Agent : header is: User-Agent: software-name/version. A comment 
can be attached enclosed in parentheses to give more specific information. For example, operating system, display size, 
supported software extensions, script libraries, etc. The format of the comment is, however, not specified in [9]. 



4.4.5 Server role in capability negotiation 



The server may request the capabilities of a client whenever required, and shall enquire of the client's capabilities prior 
to making each transaction resulting in a set of transfers to the client; the characteristics which may be reported in the 
client capability report are identified in the list above. 

In server-driven negotiation the server signals to the client that the response entity was selected from a set of available 
representation. To do this, the server attaches the Vary : response header in the response to the client. The Vary : 
header includes a list of request headers. For example: 

HTTP/1.1 200 OK 

Vary: User-Agent, Accept-Language 
Content-type : application/x-wap . wmlc 
Content-language: en 

Indicates that the entity is available for multiple languages and user-agents. The selected entity is the English version. 



4.4.6 Client-driven negotiation 



If the server cannot specify an optimal version for the client basing on the CC/PP sent over to the server, the server may 
also indicate to client which type of versions are available and let the client make the decision. This method is already 
available in HTTP 1.1. In client-driven negotiation the client selects the best representation after having received an 
initial response from the server. The response from the server is a 300 Multiple Choices response and contains a 
list of available representations. The selection of the available representations may be done automatically by the client 
application or by the (human) user from a menu. 
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It is noted that there is an implicit overhead of (at least) one additional round-trip delay with client-driven negotiation. 
The client-driven negotiation will always require an additional request/response iteration, due to the fact that the initial 
response from the server to the client's initial request may be a 300 Multiple choices response, or an equivalent 
presentation of available choices. After the user has selected one of the available options, the client sends the request 
for the actual content to the server. 



4.5 User profile 



The user profile (which may consist of sub user profiles for a user) contains the characterisation of the MExE MS as 
defined by the user and service provider. Further, it is also possible for multiple users of a MExE MS to each have their 
own user profiles. The user profile is not unique to the MExE MS, and this clause identifies the usage and content of the 
user profile from a MExE perspective only, and does not identify the generic support of user profiles in general. Refer 
to UMTS 22.101 [14] for further details on the user profile. 

4.5.1 Location of, access to, and security of, tlie user profile 

As multiple user profiles may be defined, the user is able to set up or receive calls/connections associated with different 
user profiles simultaneously by securely activating a user profile (with each user profile being associated with at least 
one unique identifier). Refer to the Security clause for further details on user profile activation. 

The user's characterisation of the MExE MS in the user profile may be modified at any time by the user and the service 
provider, and changes affected at the earliest possible opportunity. 

The security clause shall apply to all user profiles at all times, whether activated or not 

The user profile is securely managed by the MExE MS, and stored in a secure area of the MExE MS (either SIM or 
ME). The service provider may also retain the user profile in the network for service optimisation. User private data in 
the user profile should not be stored in the network. 

The support of more than one user profile is not mandatory. 

4.5.2 User profile and capability negotiation relationship 

The user profile contains the user's preferences. Support of the user's preferences will depend on the capabilities of the 
device. If the capabilities change, then the degree of support of the user's preferences may change too. 

The capability negotiation between the MExE terminal and the MSE, as shown in figure 2, contains those user 
preferences which the device is able to support. 

In this way the MSE will serve a MExE terminal with the lowest common denominator of the users preferences, the 
terminal capabilities and the provided service characteristics and support the user's preferences to the maximum degree. 



User 



user profile 
settings 




capability 
negotiation 



store / access 
user profile 
,SIM,MSE) 




Figure 2: Model of user profile and capability relationship 

4.5.3 Support of the user profile 

The user profile acts as a repository (which is always available in the MExE MS) defining the MExE MS behaviour. 
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MExE preferences and personalisation are supported in the user profile (e.g. UMTS portability and support of VHE 
defined in [12] and other 22-series specifications), which in turn is based on the Composite Capability/Preference 
Profile (CC/PP) specification from W3C [16]. 

MExE preferences and personalisation may not only be recorded directly in the user profile as supported by CC/PP (the 
direct referencing mechanism), but may also be retrieved from a URL (the indirect referencing mechanism). 

Generally, the user profile's CC/PP framework provides the mechanism for the standardised format of preferences, and 
its use of Resource Description Framework (RDF) permits the interoperable encoding of MExE preferences and 
personalisation. Future extensions will be supported by the W3C mechanism, allowing for evolution and development 
of MExE preferences and personalisation. 

The set of preferences which are supported in the user profile consists of the following: - 

• user interface personalisation 

the user's personalisation of the user interface. 

• service personalisation and management 

the user's generic service management information. 

The coding and presentation of the above characteristics in the user profile is defined by the Composite 
Capability/Preference Profile (CC/PP) specification from W3C [16], and referenced by the MExE capability negotiation 
in clause 4.4. 

The following user preference information is supported by UAProf [17]. A MExE terminal shall support (but not be 
limited to) the following properties in the UAProf schema for user preference information: 

• CcppAcceptLanguage User's preference for document language 

• DownloadableSoftwareSupport User's preference for accepting downloadable software 

• PreferenceForFrames User's preference for displaying frames 

• PushMsgPriority User's settings for WAP Push message priorities 

Also, there is support for indicating terminal's capabilities related to UI features, e.g. capability for displaying images or 
frames, as well as capability information about input and output methods. 

E.g. the following preference information is for future consideration: 

• Maximum size and time of transfer and other preferences related to transferring the content 

• User's preferences for input/output methods and other preference parameters related to user interface management 

• User's preferences for memory usage 

• Service-related parameters (eg. voice mail numbers, etc.) 



4.6 User interface personalisation 



The MS interface consists of the buttons, menus, screens and MMI as designed and provided by the MS manufacturer; 
the nature of this MS interface is naturally evolving, MS specific and proprietary to the individual manufacturers of the 
industry. This interface is the one normally seen by the user in normal operation of his MS. This specification does not 
place any requirements or limitations on the individual manufacturers' MS interface. 

The MExE MMI, in turn, is the interface available to the user to support MExE services and functionality on the MS. 
The nature of the MExE MMI interface, like the normal MS interface described above, is not standardised in any way, 
to allow for manufacturer innovation, cater for evolving market needs, and permit manufacturer differentiation. The 
MExE MMI, depending on different manufacturer implementations, may consist of the normal MS interface, the normal 
MS interface with modifications, a different interface to the normal MS interface, or some combinations thereof etc. 
MExE services operate within, and using the capabilities of, the MExE MMI. 
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User interface personalisation consists of two parts. The first part refers to the user's ability to request, and verify, the 
preferred changes to the user interface; thus the user's preferences, as supported by the specific MS, require to be 
recorded. The second part refers to the MExE MS's support of the user's preferences for the interface, within the 
capabilities of an MS. By defining the user interface personalisation to consist of two stages, the preferences which 
have been recorded by the user may be transferred (as part of the user profile, eg. CcppAcceptLanguage and/or 
PreferenceForFrames), and thereby provide portability of the user's preferences. 

4.6.1 MExE user interface personalisation 

Personalisation of the user interface offers the MExE Service Environment and or the user, the ability to inform the 
MExE MS of the desired extent of personalisation. All support of the user interface personalisation is optional, not 
mandatory on any class of MS, and subject to the capabilities of the MS. Depending on the capability of the MS, the 
personalisation may be fully supported, partially supported, interpreted or ignored. 

Personalisation of the user interface is not restricted to modifying the appearance of the MMI, but also the modification 
of MMI parameters (e.g. programming of the voicemail number). The user's personalisation of the interface is retained 
as part of the user profile. 

4.6.2 Support of MExE user interface personalisation 

MExE user interface personalisation is supported via the preferences in the user profile, which in turn is based on the 
Composite Capability/Preference Profile (CC/PP) specification from W3C [16]. 

User interface personalisation may not only be reported in the CC/PP request to the server (the direct referencing 
mechanism), but indeed the client may point to a URL (the indirect referencing mechanism) from where the user 
interface personalisation preferences may be retrieved. 

Generally, the user profile's CC/PP framework provides the mechanism for the standardised format of preferences, and 
its use of Resource Description Framework (RDF) permits the interoperable encoding of user interface personalisation. 
Future extensions will be supported by the W3C mechanism, allowing for evolution and development of MExE user 
interface personalisation. 



4.7 Management of services 



The MExE ME shall be capable of supporting services in a standard (WAP or Java) execution environment 
independently of the MExE ME manufacturer. Management of services provides the user with the capability to 

• discover services 

• configure services 

• control the transfer and execution of services 

• terminate or suspend executing services 
on his MExE MS. 



4.7.1 Service discovery 



A MExE user is able to request (or be informed about), the range of MExE services available from the MExE server to 
which it is connected. Support for the request, and transfer, of information on MExE services from the MExE server is 
primarily provided by the use of the capability negotiation mechanism. 

All services available in the network continue to be available to the user, in addition to MExE services. 

An example of an alternative means of possibly receiving information on MExE services, is the use of an application on 
the MExE MS which the user interrogates to provide services information (from various sources), and which in turn then 
obtains such information and presents it to the user. Such an example is not subject to standardisation. 
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4.7.2 Service configuration 



• 



The user controls whether a service transferred to the MExE MS is also automatically configured in the MS. 
Configuration of a service may result in changes to user interface using icons, browsers or menus as applicable 
depending on the capability of the MExE MS to support them. The service name may be contained in the 
package in which it was received (i.e. a JAR file or script), assigned by the user during configuration, or some 
other means. If service automatic configuration is enabled, the user is notified of the automatic service 
configuration once it is completed. 

In the event that there is no authorisation for the automatic configuration of a transferred service, the user is 
notified that it was not configured. 

The user controls which services may be automatically configured. 

Subsequent user modification of a service's configuration (e.g. by modification of use profile settings) shall take 
effect at the earliest possible opportunity thereafter. 



4.7.3 Service management 

• The MExE MS shall support the ability to determine which services are transferred to, resident, configured or 
executing on the MS. The information relating to the services includes (as a minimum) the name and version. 

• The user controls which services are permitted or denied to be transferred , resident, configured or executing on 
the MExE MS via the user profile, eg. DownloadableSoftwareSupport. The user profile permits characteristics 
such as security level, identification of specific services etc. to manage services on the MExE MS. 

4.7.4 Service termination 

• A service may terminate by itself, or be terminated by the provider of the service or by the user. The user is in 
charge of the service, except when the service provider may appropriately control the service as part of user 
support. 

• The mechanism for terminating a service is out of scope of standardisation and shall be provided on a service by 
service basis by the provider of the service. 

4.7.5 Service deletion 

• A service may be deleted (i.e. removed) from the MExE with the authorisation of the user. The deletion may be 
initiated by the authoriser of the service or by the user. 

4.8 Virtual home environment 

Virtual Home Environment (VHE) (see [11] and [12]) is defined as a concept for personalised service portability across 
network boundaries and between terminals. MExE is identified by VHE as one of the mechanisms which may be used 
to support VHE. 

VHE presents the same look and feel depending on the capabilities of the serving network and the capabilities of the 
terminal in use, with any limitations in the terminal being indicated to the user when the terminal is changed. Services 
that are available/unavailable will be displayed in a way that is familiar to the user no matter what class of terminal is 
used. 

With the general ability of the MExE requirements and functionality to support VHE requirements, MExE shall support 
the Virtual Home Environment system concept. 

The characteristics of the VHE (to reflect any user or home environment modification of the user's VHE) shall be stored 
as part of the user profile. Access and modification of the user profile) to support:- 

• identification of subscribed services 

• service personalisation. 
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• user interface personalisation 

shall be supported by the MExE APIs (when available). 

4.9 User control of application connections 

• This sub-clause addresses the generic aspects of connection control supported by both WAP and Java classmark 
MExE MSs. 

• In order to allow the user to maintain control over connections on his MExE MS and the ability to initiate 
connections, the user shall be able to terminate or suspend any active connection associated with an application in 
the MExE environment of the MExE MS. The user shall be able to obtain information on all connections 
associated with applications on the MExE MS. Behaviour of the application following termination or suspension 
of its connection is undefined. 

• The specific support of connection control by WAP and Java classmark MExE MSs is identified in subsequent 
sub-clauses, the security aspects of connection control are identified in the security sub-clause, and the user 
control of connection authorisation is identified in the user profile sub-clause. 



4.1 Journalling of network events 



To support the user in monitoring and maintaining a record of (potentially chargeable) network events initiated by 
services in the MExE environment, it shall be possible for the user to request the MExE MS to maintain a record of 
network events initiated by services on the MExE MS. Support of such journalling is mandatory. 

Network events for the purposes of journalling, are defined as events which result in the origination of voice or data 
connections by a service in the MExE environment of the MExE MS. Examples of such events are:- 

Sending an SMS message 

Sending an USSD message 

Initiating a circuit switched connection 

Initiating a packet switched connection 

Sending data over a packet switched connection 

The above list is not exhaustive, but includes any (potentially chargeable) network event initiated by services in the 
MExE environment. 

The user shall be able to activate and deactivate the journalling of network events in a secure manner. The length, 
format and longevity of the journal is undefined and subject to manufacturers' discretion. 

The journal shall be managed by the ME, and not be accessible by MExE executables. 



4.10.1 Journalling requirements 



The terminal shall support the logging of network events. The user shall determine whether logging is in operation or not 
and the events that are logged. The size and format of the log is not the subject of this specification. 

4.11 User notification 

It is recommended that the device should clearly display an indicator whenever network activity is in progress. 

Ideally, this would be an icon on the phone's screen which is displayed whenever the device is sending/receiving SMS, 
USSD, data call, voice call, or packets. 

However, there are certain cases when this indicator need not be displayed, especially if it is obvious by some other 
means that the device is performing network actions. 
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WAP MExE devices 



WAP MExE devices shall be based on the WAP specifications [6]. In addition to the base specifications in [6], further 
developments made in the WAP specifications shall form part of this MExE specification. 

WAP MExE devices shall implement the WAP version as specified in reference [6], or a later version, under the 
condition that the version of WAP is backward compatible with the version specified in reference [6]. 

The existing WAP specification covers security, creation and transfer of WAP executables and content, access, and 
execution. 



5.1 High level architecture 



The WAP architecture provides a scaleable and extensible environment for application development for mobile 
communication devices. This is achieved through a layered design of the entire protocol stack. 

The key features of WAP include: 



• 



Markup language (WML) and a script language (WMLScript) designed to create applications on the small displays 
of handheld devices. WML does not assume a QWERTY keyboard and a mouse is available for user input. Unlike 
the flat structure of HTML documents, WML documents are divided into a set of well defined units of user 
interactions. One unit of interaction is called a card, and services are created by letting the user navigate back and 
forth between cards from one or several WML documents. WML has a smaller set of markup tags that makes it 
more appropriate to implement in handheld devices, than, say, HTML. 

• Light-weight protocol stack to minimise the required bandwidth and to guarantee that a maximum number of 
wireless network types can run WAP applications. For example, GSM SMS/USSD, circuit switched data (CSD), 
and GPRS. 

• A framework for Wireless Telephony Applications (WTA) allows access to telephony functionality such as call 
control, phone book and messaging from within WMLScript scripts. This allows operators to develop telephony 
applications integrated into WMLAVMLScript services. 

Since WAP is based on a scalable layered architecture, each layer can develop independently of the others. This makes 
it possible to switch onto new bearers, to use new transport protocols, without major changes in the other layers. 



5.2 Optionality 



Mandatory and optional components of WAP are specified in the WAP specifications. Services and applications shall be 
able to determine the presence of optional parts of the functionality. 

5.3 Call control 

WAP telephony services are written in WML and WMLScript. The WAP Telephony API (WTAI) exposes telephony 
functions to service authors as a set of libraries. The WTAI function libraries can be accessed from WML as URIs, and 
from WMLScript as script functions. The following libraries have been specified: 

• Public library 

This includes functions that are available in all networks, and can be provided by any third party service provider; 
and not only the network operator. The user must acknowledge the function before it is carried out. One function 
has been specified. It can be used to initiate a mobile originated call. 

• Network Common library 

This includes functions that are available in all networks, and can be provided only by the network operator. 
Functions for advanced call control, accessing the phonebook, and sending and reading network text (SMS) have 
been specified. 
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• Network Specific library 

Functions that are only available in certain types of networks, and can be provided only by the network operator. 
For GSM, functions for call reject, call hold, call transfer, and multiparty have been specified. 

The WML and WMLScript author uses the WTAI libraries to create web services for mobile phones with telephony 
capabilities. 

Call control shall be performed using WTA authenticated scripts. 

5.4 Local phonebook 

WAP Telephony API (WTAI) is used to access the information stored in the phonebook on the ME or the SIM. 
Phonebook entries consist of name, number and identity. Phonebook entries can be read, written, deleted, and searched 
for. 

5.5 Services 

WAP is a general purpose application based on World Wide Web (WWW) technologies and philosophies. Many 
services can be provided to both WAP clients and traditional WWW clients, from the same server. Services are created 
based on the same information space. The major difference is the user interface. The user interface of WAP services is 
realised by the Wireless Markup Language, WML [6], and has a menu tree oriented structure, instead of the traditional 
flat structure of HTML pages. 

Typical WAP services provided to mobile phones may include (this list is not exhaustive): 

• News • Telephony Services 

• Weather information • Time Tables 

• Package Tracking • Access to corporate databases 

• Stocks • Sports 

5.5.1 User interface 

The user interface of WAP services is realised by the Wireless Markup Language, WML [6]. WML does not define the 
user interface itself, the implementation of the browser defines how the WML data is presented to the user (e.g. 
hyperlinks are blue and underlined). The script language, WMLScript [6], may be used to enhance the standard 
browsing and presentation facilities of WML with behavioural capabilities, and to access the device and its peripheral 
functionality. 



5.5.2 Access points 



Services may be hosted on standard HTTP servers and can be created with proven technologies; CGI, Java Servlets. 
URLs are used to address services. 

The WAP network topology is shown in figure 3. 
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Figure 3: WAP network topology 

Mobile phones access services by sending a request with a URI to the WAP gateway. The URI is used to identify the 
origin server on which the service is available. The request is sent from the mobile phone by the WAP protocols over 
one of the available bearer networks. The WAP Gateway is a WAP to HTTP/1.1 proxy that translates the WAP request 
into an HTTP/1 . 1 request (from binary form to text). The HTTP/1 . 1 request is passed on to the server identified by the 
URI. 

The HTTP server may have multiple access points to various databases and other services available in the infrastructure 
network. Once the request has been serviced a response is sent back to the WAP Gateway, which in turn translates it into 
a WAP response (from text to binary form) and sends it down to the mobile phone. 

Note that WAP does not specify anything "behind" the WAP Gateway. However it is assumed that the origin server is an 
HTTP/1.1 server, and that the WAP Gateway has access to the TCP/IP network on which the origin server is hosted. 



5.5.3 Transferring 



The core of WSP [6] is a binary version of the Hypertext Transfer Protocol - HTTP/1. 1 [9]. The core function of WSP 
is the same as for HTTP/1.1. A client sends a request to the server using an appropriate request method with a URI and 
information about the client. The server responds with a status code and possibly (if success) the requested content. 

There is a differentiation between an origin server and a WSP server. The origin server is where the content is stored, 
and the WSP server is where the WSP session terminates. The WSP server is also typically the WAP gateway. 

In addition to the basic HTTP/1.1 function, WSP has some functions that can not be found in HTTP/1.1, they are; 

• Session Establishment and Management 

Before a request is sent, the WSP client can establish a session with the server. During session establishment the 
client and server exchange static headers. The header are cached for the duration of the session, thus they need to be 
sent in every single request within the session. Static headers may be: Accept headers. User-agent header, 
etc. In addition, capabilities such as supported optional protocol functions, the maximum service data unit the 
protocol can handle, the maximum number of simultaneously outstanding requests, supported header code pages, 
etc. can also be exchanged during session establishment 
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• Header encoding 

WSP is using a compact binary header encoding to minimise the number of bytes sent over the air. 

• Asynchronous transactions 

WSP allows for multiple asynchronous transactions, that is, unordered transactions. 

• Transaction Abort 

WSP support abortion of an outstanding transaction. 

• Datagram transport 

WSP together with the helper protocol Wireless Transaction Protocol, WTP [9], can run over a datagram transport 
such as SMS or UDP. The WDP can also be used for non-IP bearers. 

• Push 

WSP supports the push of data from server to client. This can be done within and outside of a session. It can be 
done with and without acknowledgement from the client. Push of indications down to mobile phones is an essential 
function many wireless applications. 

5.5.3.1 WSP and HTTP/1 .1 Proxy Function 

The WAP Architecture is a client-proxy-server architecture. The client is typically a mobile phone, the data gateway is 
the WAP Gateway and the server is the origin server (a standard HTTP server). The WAP Gateway translates the binary 
WSP header into text formatted HTTP/1 . 1 headers and passes them on to the origin server. In the opposite direction the 
WAP Gateway translates the text formatted HTTP/1.1 header into binary WSP headers. If the WAP Gateway receives a 
header it does not recognise it simply passes it on as an unknown header. Unknown headers that are not part of the WSP 
Header Code page or Extended code pages (negotiated at session establishment) are sent in plain text for the client to 
interpret as best it can. 



Java MExE devices 



Java MExE devices shall be based on the MExE API for Java, which defines the required and optional components of 
Java APIs that shall be used to realise a MExE compliant device. 

The MExE API for Java primarily defines the functions available to a Java-based MExE device such that services 
(specified in the form of Java classes and interfaces) can control such a device in a standardised way. 

Many aspects of the MExE API specification are optional. Services and applications shall be able to determine the 
presence of optional parts of the functionality. When optional parts of the functionality are implemented, the MExE API 
shall be supported. 
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6.1 High level architecture 
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Figure 4: Basic functional architecture of a Java MExE device 

The functional architecture of a Java MExE device is shown in figure 4. Java applets, applications, and services access 
functionality via the MExE API for Java. The MExE API is based on a combination of optional Java APIs approved by 
Sun Microsystems and the Wireless Profile of the JavaPhone API [4] as defined by the JavaPhone Expert Group. The 
JavaPhone API is based on the PersonalJava API [3] defined by Sun Microsystems. 

6.2 High level functions 
6.2.1 Optionality 

The use of Java encourages development of modular interfaces and minimal required functionality. Additional 
functionality is provided by optional APIs specified in terms of the Java language. In general, optionality is specified in 
terms of Java packages. Packages are containers for the highest level of functionality in the Java language. In some 
cases, optionality is specified in terms of Java classes and interfaces. Classes and interfaces are elements contained 
inside packages. 

The following table 1 specifies the Sun Microsystems defined optionality of the Wireless Profile of the JavaPhone APIs. 
Within some of the packages, certain classes and methods may be individually specified as optional by the JavaPhone 
API specification. 

Where a mandatory package is identified, it is implicit that any packages called by that mandatory package are also 
mandatory. 
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Table 1 : Optionality of the Wireless Profile of the JavaPhone APIs 



JavaPhone API 


Java package 


Optionality 


Addressbook 


Javax.pim. addressbook 


Mandatory 


User Profile 


Javax.pim.userprofile 


Mandatory 


Calendar 


Javax.pim.calendar 


Mandatory 


Network 


Java.net 


Mandatory 


Datagram 


Javax.net.datagram 


Mandatory 


Power Monitor 


Javax.power.monitor 


Mandatory 


Power Management 


Javax.power.management 


Optional 


Install 


Javax.install 


Optional 


Communications 


Java.comm 


Optional 


SSL 


Javax.net.ssI 


Optional 


JTAPI Core Package 


Javax.telephony 


Mandatory 


JTAPI Core Capabilities Package 


Javax.telephony.capabilities 


Mandatory 


JTAPI Core Events Package 


Javax.telephony.events 


Mandatory 


JTAPI Call Control Package 


Javax.telephony.callcontrol 


Optional 


JTAPI Call Control Capabilities Package 


Javax.telephony.callcontrol.capabilities 


Optional 


JTAPI Call Control Events Package 


Javax.telephony.callcontrol. events 


Optional 


JTAPI Phone Package 


Javax.telephony.phone 


Optional 


JTAPI Phone Capabilities Package 


Javax.telephony.phone. capabilities 


Optional 


JTAPI Phone Events Package 


Javax.telephony.phone. events 


Optional 


JTAPI Mobile Package 


Javax.telephony.mobile 


Mandatory 




Java.math 


Optional 




Java.rmi 


Optional 




Java.rmi.dgc 


Optional 




Java.rmi. registry 


Optional 




Java.rmi. server 


Optional 




Java.security 


Optional 




Java.security.interfaces 


Optional 




Java.sql 


Optional 




Java.io 


Optional 



6.2.2 Required and optional PersonalJava APIs 

Java MExE devices shall support the PersonalJava specification [3]. The PersonalJava APIs provide a standardised and 
readily implementable execution environment as a means for applications, applets, and content: 

• to access and personalise the user interface via the Java. awt packages 

• to utilise both Internet and Intranet connections via the java.net package 

6.2.3 Required and optional JavaPhone APIs 

The JavaPhone APIs extend the PersonalJava APIs to provide functionality unique to telephony devices. Java MExE 
devices shall support the Wireless Profile of the JavaPhone API specification [4]. Java MExE devices shall support all 
APIs specified as required by the Wireless Profile in the JavaPhone API specification. All APIs that are optional in the 
Wireless Profile shall be optional in Java MExE devices. 

6.2.3.1 Application installation 

Java MExE devices shall support the following JAR file manifest entries (as described in the JavaPhone specification) 
as described below: 

• Implementation-Title 

the Implementation-Title shall be used in any textual description of the application which is displayed in the UI 
element used to launch the application. E.g. the text displayed with an icon. 

• Main-Icon 

if icons are used as elements to launch the application, then the icon file within the JAR file named by the Main-Icon 
attribute shall be displayed, and may be scaled if desired. 

• Main-Class and Class-Path 
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when the application is launched, the MExE Java VM shall be supplied with the classpath and shall call the main() 
method in the class named by the Main-Class attribute. 

6.2.3.2 Power 

Java MExE devices shall support the Power Monitor package (javax.power.monitor) as specified by the JavaPhone API 
to access the power level of the device and receive notifications concerning changes in power states. 

Note that the Power Monitor package does not specify the minimum required events that should be generated under 
certain circumstances. A MExE Java device shall at least implement the following event generation: 

• BatteryCritical 

shall be generated when the battery is at a critically low level. 

• BatteryNormal 

shall be generated when the battery is no longer low. 
All the other event generation should be supported by the implementation. 

6.2.4 Required and optional MExE APIs 

A Java MExE device shall not be required to support any other Java APIs. 

A Java MExE device may optionally support any other Java APIs which comply with the MExE security requirements in 
table 3, such as: 



• OCF SmartCard API OpenCard, available from [21]. If the ME supports smartcards other than the SIM, and the 
smartcard is open to 3'^'' 
used to access the card. 



smartcard is open to 3'^'' party applications, then the opencard. core. terminal section of the OpenCard API may be 



6.2.5 Mandated services and applications 

6.2.5.1 WAP browser support 

To provide backward compatibility to MExE classmark 1, i.e. allow access to services designed for MExE classmark 1 
devices, classmark 2 devices must feature a pre-installed or pre-loaded WAP browser that is capable of rendering at 
least the following content formats: 

• tokenised WML documents ("WML decks") 

• WMLscript bytecode 

• A WAP service in a MExE classmark 2 MS shall execute in the same manner as it executes in a MExE classmark 1 
MS. 

• A WAP service in a MExE classmark 2 MS shall execute in the same manner as it executes in a MExE classmark 
IMS. 

Other WML formats (such as textual WML documents or textual WMLscripts) are optional. 

The pre-installed/pre-loaded WAP browser may be upgraded, replaced or extended by transferring, a replacement, 
extension or plug-in mechanism to the MS. Depending on user preferences identified in the user profile and the terminal 
capabilities, the pre-installed or pre-loaded WAP browser may be overwritten or the new browser stored in a different 
location. 

6.2.5.2 Network protocol support 

Support for network protocols in Java MExE devices is specified in the following table 2: 
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Table 2: Support for network protocols 



Protocol 


Optlonallty 


HTTP/1.1 [9] 


Mandatory 


HTTPS 


Mandatory 


Gopher 


Optional 


ftp 


Optional 


mailto [25] 


Mandatory 


File 


Optional 



6.2.6 Datagram recipient addressing 



The Datagram API (as specified by JavaPhone) may resolve server/service names using a name resolution service. The 
MExE Java implementation shall at least be able to resolve names using the addressbook. 

The implementation of the Datagram API shall support use of the addressbook to resolve names: The addressbook 
entries shall be searched for items whose name matches the server/service name by the Datagram API implementation in 
order to resolve names to actual addresses. It shall look for an item of type "FN" with a value equal to the server name, 
using the following syntax: 

server_name: *mostchars 
e.g. "The PIZZA Hut". 

Then it shall search for aggregate fields named by the service name concatenated to "X-DATAGRAM-", the field name 
which is named according to the following syntax: 



field name 



service name 



"X-DATAGRAM-" service_name 
*mostchars 



Then it shall use the value of the aggregate attributes which use this field. These strings shall specify in order, the 
preferred and available protocols and addresses for the named server/service. The string value in each X- 
DATAGRAM... field shall be formatted as so (inspired by RFC 1738 [22]): 



address 


= 


primary_name "{" primary_addr "}" *[ secondary_name "{" se 


primary_name 


= 


wdp_name 1 udp_name 1 sms_name 1 any_name 


primary_addr 


= 


internet_addr 1 phone_number 1 port 1 httpurl 1 *unreserved 


secondary_name 


= 


sms_name 1 url_name 1 sms_center_name 1 ip_name 1 any_name 


wdp_name 


= 


"WDP" 


udp_name 


= 


"UDP" 


sms_name 


= 


"SMS" 


url_name 


= 


"URL" 


sms_center_name 


= 


"CENTER" 


ip_name 


= 


"IP" 


any_name 


= 


1 *alphadigit 


secondary_addr 


= 


internet_addr 1 phone_number 1 port 1 httpurl 1 *unreserved 


internet_addr 


= 


hostname 1 hostnumber 


phone_number 


= 


*phonechar 


httpurl 


= 


"http://" host [ "/" hpath [ "?" search ]] 


host 


= 


hostname 1 hostnumber 


hostname 


= 


*[ domainlabel "." ] toplabel 


domainlabel 


= 


alphadigit 1 alphadigit *[ alphadigit 1 "-" ] alphadigit 


toplabel 


= 


alpha 1 alpha *[ alphadigit 1 "-" ] alphadigit 
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hostnumber 

port 

hpath 

hsegment 

search 

lowalpha 



hialpha 



alphadigit 



= digits "." digits "." digits "." digits 

= digits 

= hsegment *[ "/" hsegment ] 

= [ "~" ] *[ uchar I ";" I ":" I "@" I "&" I "=" ] 

= *[ uchar I";" I":" l"@" I "&" 1"="] 

= "a" I "b" I "c" I "d" I "e" I "f I "g" I "h" I 

"i" I "j" I "k" I "1" I "m" I "n" I "o" I "p" I 

"q" I "r" I "s" I "t" I "u" I "v" I "w" I "x" I 

"y" I "z" 
= "A" I "B" I "C" I "D" I "E" I "F" I "G" I "H" I "I" I 

"J" I "K" I "L" I "M" I "N" I "O" I "P" I "Q" I "R" I 

ttQtt I tf-ptt I "TT" I "\7'" I "\X/" I "^^" I "V" I "^7" 

= alpha I digit 



alpha 


= 


lowalpha 1 hialpha 


phonechar 


= 


"+" 1 digit l"#"l"*"l"C"l"D"l"c"l"d" 


digits 


= 


1 *digit 


digit 


= 


"0"l"l"l"2"l"3"l"4"l"5"l"6"l"7"l 


safe 


= 


"$" 1 "-" 1 "_" 1 "." 1 "+" 


extra 


= 


"!"l"*"l I"("l")"l"," 


hex 


= 


digit 1 "A" 1 "B" 1 "C" 1 "D" 1 "E" 1 "F" 1 
"a" 1 "b" 1 "c" 1 "d" 1 "e" 1 "f 


escape 


= 


"%"hexhex 


unreserved 


= 


alpha 1 digit 1 safe 1 extra 


uchar 


= 


unreserved 1 escape 


mostchars 


= 


unreserved 1 " " 



As a minimum, the following transport/bearer combinations shall be supported if the device supports the 
bearer/transport combination: 



Transport/bearer 
combination 


Value of 
primary name 


Syntax of 
primary_addr 


Value of 
secondary name 


Syntax of 
secondary_addr 


WDP over SMS 


WDP 


port 


SMS 


phone number 


SMS 


SMS 


phone number 






WDP over HTTP 


WDP 


port 


URL 


httpurl 


UDPoverIP 


UDP 


port 


IP 


internet addr 



For example: 

WAP Datagram over SMS: "WDP=358,SMS={+358503583862}" 

SMS: "SMS={+358503583862}" 

WDP over HTTP: "WDP={ 1 234 },URL={ http://somewhere.on.the. web/path/name}" 

UDP over IP: "UDP={ 1234},IP={ 147.23.120.2}" 

If the service centre number is specified for SMS, then the secondary_name shall be "CENTER" and secondary_addr 
shall be the phone number. If it is not present, then it shall be derived from the default service center. 

7 Charging 

7.1 Generic charging support 

The standard GSM/UMTS charging records contain information sufficient to associate bearer usage and SMS/USSD 
messages with a subscriber. 

Third party service providers and/or service providers may define charging regimes for MExE services (e.g. on a MExE 
or WAP server), however they are outside the scope of standardisation. 
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7.2 WAP charging support 



The WAP protocol suite in [6], with upgrades as identified in this specification, does not specify mechanisms for 
charging (e.g. charging records) or subscription management. WAP is bearer independent and is running as an 
appHcation on top of the bearer network. However the WAP architecture suggests that appropriate charging information 
can be collected in the WAP Gateway; the point of convergence for all WAP traffic. 

WAP support the concept of a session. A session is established between the mobile and the WAP Gateway. The duration 
of a session can be days, weeks or even months. The session can be associated with a particular subscription in the WAP 
Gateway. The WAP security protocol can be used for authentication of the subscriber. 



7.3 Java charging support 



MExE Java devices do not require any additional specific charging (e.g. charging records) or subscription management. 
Java usage of network resources is bearer independent and runs as applications on top of the bearer network. 



8 Security 

8.1 Generic security 

In order to manage the MExE and prevent attack from unfriendly sources or transferred applications unintentionally 
damaging the MExE device a security system is required. This section defines the MExE security architecture. 

The basis of MExE security is 

• a framework of permissions which defines the permissions transferred MExE executables have within the MExE 
MS 

• the secure storage of these permissions (and permission type as defined in clause 8.3) 

• conditions within the execution environment that ensure that MExE executables can only perform actions for which 
they have permission. 

The MExE permissions framework is defined in GSM 02.57 and is as follows (there is no implied hierarchy): 

• MExE Security Operator Domain (MExE executables authorised by the HPLMN operator); 

• MExE Security Manufacturer Domain (MExE executables authorised by the terminal manufacturer); 

• MExE Security Trusted Third Party Domain (trusted MExE executables authorised by trusted third parties); 

• Support for the three domains is mandatory. 

• Untrusted MExE executables are not in a specific domain, and have very reduced privileges as described in 
section 8.2. 

8.2 IVIExE executable permissions 

The following table 3 specifies the permissions of each security domain. 

The actions listed in the security table 3 are generic actions. Application programming interfaces (APIs) which are 
intrinsically part of the MExE implementation may directly or indirectly cause these actions to be performed. When 
these actions occur, whether directly or indirectly called by such an API, the security restrictions shall apply. 

Explicit user permission is required for all actions by MExE executables in all domains. Types of user permission are 
defined in clause 8.3 
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File access is not permitted for untrusted MExE executables, except that untrusted Java applications can access files 
only in the application's own directory. Untrusted MExE executables are not permitted access to any actions which 
access the phone functionality (phone functionality includes all the actions in the table 3) except for this one qualified 
exception, and as further identified in 8.2.1. 

Actions available using interfaces giving access to the phone functionality (either in existence at the time of approval of 
this specification or not) that are not listed or not of the same category as a group in the security table 3 can be accessed 
by all trusted MExE executables. 
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Table 3: Security domains and actions 





MExE Security Domains 


Actions 


Operator 


Manufacturer 


Trusted Third 
Party 


User private data access ^ 

1 . Read 

2. Write 

3. Get properties 

4. Delete 

5. Get Location Information 

6. Read stored SMS 

7. Delete stored SMS 


Yes' 


Network access 

1 . Initiate a voice/data connection ^ 

2. Accept a voice/data connection ^ 

3. Call forward "^ 

4. Multiparty call '^ 

5. Call deflection "* 

6. Explicit call transfer '^ 

7. Terminate an existing connection 

8. Hold an existing connection 

9. Resume an existing connection 

10. Send point-point message (e.g. SMS, 
USSD)^ 

11. Generate DTMF 

12. Query network status 

13. Get signal level 

14. Get call list 


Yes 


Yes" 


Lifecycle management 

1 . Install a MExE Executable 

2. Uninstall a MExE executable 


Yes 


Miscellaneous functions 

1 . Get manufacturer software version 


Yes 


Certificate management 

1 . Install a certificate for a given domain 

2. Uninstall a certificate for a given 
domain 

3. Replace a certificate for a given 
domain 


Yes' 


Audio access 

1 . Sound generation to speaker (e.g. via 
stream) 

2. Select Melody 

3. Set speaker volume 

4. Get melody list 


Yes 


Power management 

1 . Monitor the power state 

2. Change the power state 


Yes 


Network selection/operator data 
access 

1. GetlMSI 

2. Get home network 

3. Select network 


Yes 


No 
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Table 3 (concluded): Security domains and actions 





MExE Security Domains 


Actions 


Operator 


Manufacturer 


Trusted Third 
Party 


Device core function access 

1 . Start/stop radio 

2. Turn on/off device 


No 






User profile management 

1 . Activate a user profile 

2. Modify a user profile 


No 


User preference management 

Modify user preferences 


Yes' 


Legend for above footnotes:- 

^ - User private data includes user files, phonebook, etc located on the MS. 

^ - The user shall be able to specify data access permissions within the capabilities of the 
device. 

^ - A network connection may be via any supported bearer service 

'^- Multiparty, deflection, and explicit call transfer shall be permitted only to numbers 
explicitly supplied by the user to the MExE Executable. Modification of call forward 
numbers stored in the network shall only be permitted to numbers explicitly supplied 
by the user to the operator. 

^ - Only the organisation whose public key is certified (or the organisation that certified 
the public key) can add, delete or replace a particular certificate. 

^- The Trusted Third Party domain's permission to access the networking action depends 
on the provisioning mechanism as described in section 8.15 

^-Trusted applications only have permission to modify user preferences, and not to 
activate or de-activate them. The user shall be able to specify for each domain, the 
preferences that applications in that domain can access. All other preferences shall 
not be accessible to that domain. The default shall be that there is no access. 



The lists in the groups in the table 3 are not exhaustive, and other actions which are of the same category shall be 
included in the group for the purposes of requesting user permission. 

8.2.1 MExE executable permissions for untrusted applications 

Clause 8.2 identifies the permissions for MExE executables in the 3 domains (operator, MS manufacturer and Trusted 
Third Party). The permissions do not apply to untrusted applications which are not permitted to execute within the 
domains. 

In order to facilitate untrusted applications having some limited access to MExE MS functionality beyond their very 
limited privileges, the following specific network access permissions in Table 3 are extended to untrusted applications:- 

• Initiate a voice/data connection 

Untrusted applications shall be able to make calls under the following conditions. 

In addition to an untrusted application possibly displaying the number to be called to the user, the number to be 
called shall be presented to the user for permission by a provisioned functionality of the MExE MS and not by the 
application itself. (This facility would support, for example, "click to dial" button/links in an untrusted application, 
and a MExE MS provisioned functionality then represents the number to the user for confirmation.) 

• Generate DTMF 

Untrusted applications shall be able to generate DTMF tones under the following conditions. 
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An untrusted application is only permitted to send DTMF tones in a currently active call. The request to generate 
DTMF tones in the currently active call, shall result in the characters which the tones represent being presented to 
the user for permission by a provisioned functionality of the MExE MS. 

The untrusted applications permitted to use the above facilities shall be applications the user has downloaded himself, 
and not be applications that have been pushed to the user. Applications/applets on the MExE MS due to the user having 
visited a particular web site are considered to be applications that the user had downloaded himself. 

Untrusted applications shall not be permitted access to any other functions. 



8.3 User permission types 



The term "user permission" is defined to mean that the user can give permission for a specific action in one of the ways 
defined in Table 4. Blanket permission and single action permission are mandatory, and session permission is optional. 

All prompts for user permission as described in table 4 must display the alias name for the signer of the corresponding 
MExE executable. 

The user shall be prompted for user permission relating to each action group listed in the table 3. If a prompt for 
permission relates to more than one action, e.g. networking and user data, then it shall list the individual action group 
permissions which will be granted. This condition applies to any prompts relating to user permissions in table 4. 

Note that blanket permission and session permission can't be used for uninstalled MExE executables e.g. applets, 
'WMLS. 

Table 4: User Permissions 





User Permissions 


Permission 
Type 


Description 


Invocation 


Revocation 


blanket permission 


The user gives blanket 
permission to the IVIExE 
executable for the specified 
action, and the IVIExE 
executable subsequently uses 
the user's original permission 
for the identified subsequent 
actions whenever the MExE 
executable is running. 


Typically such permission 
would be given at MExE 
executable configuration or run 
time. 


The blanket permission maybe 
revoked by the user at any 
time. The user permission no 
longer applies once the MExE 
executable has been removed. 


session permission 


The user gives permission to 
the IVIExE executable for the 
specified action during a 
specific run time session of an 
IVIExE executable, and the 
IVIExE executable subsequently 
uses the user's permission for 
the identified subsequent 
actions whilst the MExE 
executable session is still 
running. 


Typically such permission 
would be given at MExE 
executable run time. 


The session permission 
maybe revoked by the user at 
any time. The user permission 
no longer applies once the 
MExE executable run time 
session has terminated. 


single action 
permission 


The user gives a single 
permission to the MExE 
executable for the specified 
action; if the MExE executable 
subsequently wishes to repeat 
the action it must again request 
the user's permission for the 
identified subsequent action. 


Typically such permission 
would be given at MExE 
executable run time. 


The user permission no longer 
applies once the action has 
terminated. 
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8.4 Operator root certificate 



The operator root certificate contains the operator root pubUc key. The MS shall support secure storage (in ME or SIM) 
for an operator root public key. The certificate contains a root public key either from the operator, or a root public key 
from a CA implicitly trusted by the operator. The ME will get the operator root public key from the secure area every 
time it needs to verify a signature, rather than cache the root public key for use in subsequent verifications. 

If the MS does not contain a valid operator root public key, then the certificate chain to MExE executable previously 
executing in the Operator Domain will be invalid, and they will be excluded from the operator domain. 

The user is not authorised to add or delete any type of operator public key or certificate. 

Optionally, the operator certificates may have a corresponding disaster-recovery key stored in the MS, enabling the 
operator to use a secure mechanism (involving the disaster-recovery key) to replace the certificate. 

There shall be no more than one valid operator root public key on the MS. 

An application signed by a operator other than the operator whose certificate is the operator certificate, shall not be able 
to execute in the Operator Domain. 

8.5 IVIanufacturer root certificate 

The manufacturer root certificate contains the manufacturer root public key. The ME shall support secure storage for a 
manufacturer root public key. The certificate contains a root public key from the manufacturer of the same device, or a 
root public key from a CA implicitly trusted by the manufacturer of the same device. 

If the ME does not contain a valid manufacturer root public key, then the certificate chain to MExE executable 
previously executing in the Manufacturer Domain will be invalid, and they will be excluded from the manufacturer 
domain. 

The user is not authorised to add or delete any type of manufacturer public key or certificate. 

The Manufacturer shall put a root public key and its corresponding optional disaster-recovery key in the device at the 
time of manufacture, and use a proprietary secure mechanism (e.g. using the disaster-recovery key) to replace the 
certificate. 

An application signed by a manufacturer other than the manufacturer whose certificate is the Manufacturer Certificate 
shall not be able to run in the Manufacturer Domain. 

There shall be no more than one valid manufacturer root public key on the MS . 

8.6 Trusted third party root certificate 

The trusted third party root certificate contains the trusted third party root public key. The ME shall support secure 
storage for a TTP root public key. The ME may contain root public key (s) from CA(s) implicitly trusted by the user. 
The user will be able to securely install (using a secure transport) or remove these root public key at any time using a 
system administrative tool. 

The Manufacturer, Operator and Administrator may at their discretion, securely install (using a secure transport) Trusted 
Third Party root public key(s) on behalf of the user, e.g. at the time of manufacture by the Manufacturer. See section 
8.14 for details of Administrator control of TTP certificate download. 

If a Trusted Third Party public key is deleted or becomes invalid, then the certificate chain to MExE executables 
previously executing in the Trusted Third Party Domain certified by that public key will become "untrusted". 

There may be any number of TTP root public keys on the MS. 

The third party domain administrator (user or other body) shall be able to enable and disable TTP root public keys. The 
process of adding/removing public keys and enabling/disabling public key are independent. 

Using a provisioned functionality, the user is able to delete a TTP public key or certificate, but not the TTP root public 
key or certificate. 
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8.7 Administrator root certificate 

The administrator root certificate contains the administrator root public key. The ME shall support secure storage for an 
administrator root public key. Only one administrator root public key shall be held on the MExE MS. 

The MExE MS shall support the administrator designation mechanism and the secure downloading of CCMs explained 
in section 8.12. 

The user is not authorised to delete an administrator root public key or certificate. 

The system shall support a mechanism (as part of a provisioned functionality and/or inherently part of the MExE 
implementation) allowing the owner of the MExE MS to manage the administrator root public key (including the 
download of a new administrator root public key) as defined in Section 8.9.4. This mechanism shall be secure so that 
only the owner can use this functionality. 

8.8 Certification and autinorisation architecture 

In order to enforce the MExE security framework a MExE capable MS is required to operate an authentication 
mechanism for verifying downloaded MExE executables. A successful authentication will result in the MExE executable 
being trusted; and able to be executed in a security domain (as determined by the root public key of its certification 
tree). 

As the MExE MS may want to authenticate content from many sources, a public key based solution is mandatory. 
Before trusting MExE executables, the MExE MS will therefore check that the MExE executable was signed with a 
private key, for which the MExE MS has the corresponding public key. The corresponding public key held in the MS 
must either be a root public key (securely installed in the MS, e.g. at manufacture) or a key provided in a certificate. 
The MExE MS must be able to verify this certificate, i.e. have the public key (as a root key or in a certificate) 
corresponding to the private key used to sign the certificate. A certificate chain is therefore mandatory. 

The requirements on authorisation and certification are given in clause 8.8.1. An example authorisation and certification 
process is described in clause 8.8.2. 



8.8.1 Certification requirements 



A MExE MS cannot verify certified MExE executables of a particular domain unless it has a root public key for that 
particular domain. 

Root public keys shall be securely installed in the MExE MS, say, at manufacture. 

It is recommended that a "disaster recovery" root public key be securely installed on the terminal, to be used to install 
new root public keys when all other root public keys on the terminal are invalid. 

Trusted Third Party Domain root public keys will typically be installed along with and integrated into the MExE ME 
browser, as is done for PC-based browsers. 

A MExE executable can only be verified if the MExE MS contains a valid root public keys corresponding to the private 
key used to sign the MExE executable. 

A MExE MS shall support at least one level of certificate under operator, manufacturer or TTP root public keys. The 
MExE MS shall support at least one level of certificate chain analysis in a signed content package, as shown in figure 5. 

A certificate (other than one containing a root public key) shall only be considered valid if it is verified by a valid root 
public key or a valid certificate already present on the MS. 

No public key shall be shared between several domains. 
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Mandatory minimum supported trust hierarchy 




Figure 5: Trust hierarchy 

The boxes below the root keys represent individual public key certificates. The solid boxes represent the minimum 
MExE requirements (e.g. support of at least one public key certificate at the first level), and the dotted boxes represent 
possible further support for public key certificates (either at the first or subsequent levels). 

8.8.2 Example certification process 

The following processes might be followed in order to securely download a Trusted Third Party application to a MExE 
MS. 

Root public keys for a number of Certification Authorities (CAs) are installed in the ME, along with the ME browser, at 
manufacture. These root public keys can be used to verify certificates for Trusted Third Party MExE executables. 

1. A third party software developer generates a private and public key pair (or obtains such a pair from a CA). 

2. The third party software developer obtains a certificate for the public key from a CA. The certificate contains the 
developer public key, signed with the private key of the CA. 

3. The 3"* party software developer adds all the certificates required in the key chain in the JAR. 

4. The MExE MS downloads a MExE executable of the third party software developer. 

5. The MExE MS verifies the certificate using the root public key, contained in the browser, of the relevant CA, and 
extracts the third party software developer public key and may store it in the certificate store for future use. 

6. The MExE MS verifies that the MExE executable was signed using the private key corresponding to the third party 
software developer public key and installs or rejects the MExE executable accordingly. 



8.9 



Signed packages used for installation 



The Java Archive (JAR) file format shall be supported on classmark 2 MExE devices for securely packaging objects that 
are to be downloaded and installed on the ME. The method for securely packaging objects for MExE classmark 1 
devices may be referenced from the WAP specifications in a future release of this specification. A MExE device may 
support other proprietary means of downloading and installing objects. 

The JAR file shall contain a manifest file that has at least the following attribute: 



MExE -Implement at ion-Type 
Whose value shall be either 

• "MExENativeLibrary" 



in the case of a MExE Native Library (as described in 8.9.1); 
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"TTPCertificate" 

in 8.9.2); 



in the case of a certificate containing a 3"^ party root public key (as described 



"Manuf acturerCertif icate" in the case of a certificate containing a manufacturer root public key (as 
described in 8.9.2); 



"OperatorCertif icate" 

described in 8.9.2); 

"AdminCertif icate" 
"CCM" 



in the case of a certificate containing an operator root public key (as 

in the case of an administrator certificate (as described in 8.9.2); or 

in the case of a CCM (as described in 8.12); or 

in the case of proprietary binaries or Java classes such as native DSP code, 



• -free-format-value- 

provisioned functionality upgrades and patches (as described in 8.9.2). 

E.g. 

MExE-Implementation-Type : MExENativeLibrary 

See figure 6. When a download of a JAR file is completed, the system installer shall read the manifest to determine what 
types of files are contained in the JAR, and install them appropriately. 

Note that a signed package containing a library which does not have a manifest attribute "MExE-Implementation- 
Type : MExENat iveLibrary " shall be considered to be some type of upgrade to libraries that are intrinsically part 
of the ME implementation rather than a "MExE native library". E.g. 

MExE-Implementation-Type : Manuf acturerUpgrade (something.dll) 

(Recommended behaviour for the server is that it uses the capability information supplied from the ME to determine 
how to offer appropriate upgrades.) 













Signature 


















Manifest (attributes) _^^^- 


















Contents (Java classes, native 
code, certificate, etc..) 





"MExE-lmplementation-Type: 



Figure 6: signed pacitages 

8.9.1 Installing MExE native libraries 

A signed native library whose signature verifies as describe in section 8.8 as belonging to the Manufacturer Domain may 
be installed as a "MExE native library". 

A MExE native library may be called by a MExE executable, and shall not compromise the MExE security system. 

Support of MExE native library signed package installation is optional. 

8.9.2 Installation of root certificates in a signed data package 

Root certificates in a signed package (whose signature verifies as described in section 8.9 to the Manufacturer root. 
Operator root, or the Administrator root), may be installed to the root public key store on the ME. Note that the 
certificate thus packaged does not necessarily belong to the manufacturer domain. The types of certificate that can be 
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present and installed by packages are given in Table 5. The ME shall store the root public key as indicated by the 
certificate type. 

When a certificate containing an Administrator root public key is thus contained in a signed package, the signed package 
(JAR) shall contain two files: the Administrator root public key and the CCM. 

8.9.3 Installation of other signed data 

A signed package of proprietary binaries or Java classes such as native DSP code, provisioned functionality upgrades 
and patches, whose signature verifies as described in section 8.8 as belonging to the Manufacturer Domain may be 
installed. The use of such binaries is outside the scope of MExE, but the manufacturer shall be responsible for ensuring 
that the integrity of MExE is not compromised. 

Support of this feature is optional. 

8.9.4 Administrator root certificate download mechanism 

Devices supporting SIMs without certificates shall at least support the following procedure to download the 
administrator root certificate. 

1. Upon sign-up with an administrator the user and administrator will make contact. 

2. The administrator service centre will obtain any required information from the user and inform the user by SMS or 
other means of the location of the administrator root certificate. 

3. The user will initiate the download of the Administrator root certificate using a signed package. 

4. Once the procedure is complete the device shall display the hash of the Administrator root public key. 

5. The user will read this information back to the administrator. If this information is correct the provisioning process 
will be complete. 

Alternative methods to download an administrator root certificate may be used where appropriate but must insure that 
the certificate is received by the device unaltered. 



8.10 WAP security 



The WTLS security model provides a flexible framework based on TLS, which is independent of the GSM security 
model. 

8.11 Java security 

There are two types of Java security [20]: sandbox, and fine grain. 

The sandbox model [18] has just one domain; there is no concept of a partly trusted domain. The sandbox meaning of 
"trusted" means it is totally unrestricted to access all system resources. 

Using the sandbox system, each MExE domain shall be implemented as running in a sandbox, configured with different 
privileges corresponding to those of the domain. 

Using the fine grain Java security system [19], each MExE domain will be a set of constraints within which a Java fine 
grain security domain can be configured. 



8.11.1 Java applet certification 



Support for trusted applets is optional. Although a Java application shall be executed in a trusted domain if its 
certification can be validated, a Java Applet will not necessarily be executed in a trusted domain even if it does have a 
valid signature. It will be up to the implementers to decide if "trusted" Applets will be supported. (In certain 
implementations, all Applets may be always executed as "untrusted".) 
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8. 11 .2 Java application signature verification 

The verification of the certification of the application or applet shall be performed as described in section 8.8. 

8.1 1 .3 Java loading native libraries 

The MExE Java VM may be able to load native libraries that are intrinsically part of the ME implementation, and MExE 
native libraries. The MExE Java VM shall not load other native libraries. 

8.12 Certificate configuration message (CCM) 

The MExE device shall use the CCM to determine the third party certificates (and only the TTP certificates) that are 
trusted for use on the MExE MS. The CCM may be periodically fetched or downloaded to a MExE device by the 
Administrator to dynamically configure the trusted third party list using the mechanisms defined in section 8.15.2. The 
Certificate Configuration Message shall be as shown in Figure 7. This message is essentially a simplified version of a 
certificate revocation list to satisfy a particular use case. More complex usage requires a full certificate revocation list. 

The MExE device may additionally support other means of enabling/disabling root certificates. 



Version 
(1 byte) 


CertificateAdvice 
(1 byte) 




Listlength, the total number of 
bytes of fingerprints and 
signature 

(2 bytes) 




hashtype 
(1 byte) 


hashvalue (fingerprint 1) 

( 1 6 bytes if MD5 or 20 bytes if SHA- 1 ) 


hashtype 

(1 byte) 


hashvalue (fingerprint 2) 

( 1 6 bytes if MD5 or 20 bytes if SHA- 1 ) 


hashtype 

(1 byte) 


hashvalue (fingerprint 3) 

( 1 6 bytes if MD5 or 20 bytes if SHA- 1 ) 


hashtype 
(1 byte) 


hashvalue (fingerprint 4) 

( 1 6 bytes if MD5 or 20 bytes if SHA- 1 ) 



hashtype 
(1 byte) 



hashvalue (fingerprint 'n') 

(16 bytes if MD5 or 20 bytes if SHA-1) 



hashtype 
(1 byte) 



Signature (the administrator signature, to confirm that the above TTP fingerprint list is valid) 
((listlength - (bytes used by fingerprints)) bytes) 



Figure 7: Logical CCM format 
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CCM octet order is left to right (see figure 8), commencing with "Version" followed by "certificateAdvice", and the bit 
order is from most significant bit to least significant bit. The most significant byte is the leftmost byte, and the least 
significant byte is the rightmost byte. 



Version 


Certificate advice 


MSB Ust length 


LSB List length 


5 


6 


7 


8 


Hashtype 1 


Hashl value octet 1 


Hashl value octet 2 


Hashl value octet 3 


9 


10 


11 


12 


Hashl value octet 4 


Hashl value octet 5 


Hashl value octet 6 


Hashl value octet 7 


• • • 


Hashl value last octet 


Hashtype 2 


Hash2 value octet 1 


Hash2 value octet 2 


• • • 


Hash2 value second 
last octet 


Hash2 value last 
octet 


Hashtype 
(signature) 


Signature value 1 



n-3 



n-2 



n-1 



Signature value m-3 Signature value m-2 Signature value m-1 Signature value m 



Figure 8: CCM octet order 

version = For MExE-98 the CCM format version is 0. All other values are reserved for future use. 

certificateAdvice = enumerated { enable all present and future TTP certificates (0), disable all present and future TTP 
certificates (1), enable present list only (2), enable CCM list (3), disable CCM list (4) }. All other values are reserved for 
future use. 

listLength = The total length of the following list. Shall be zero when certificateAdvice = enable-all or disable-all. 

hashType = enumerated { signature (0), MD5 (1), SHA-1 (2) } All other values are reserved for future use. 

hashLength = The number of octets output by the selected hash type (16 for MD5 [23] and 20 for SHA-1 [24]). 

The list entries shall contain certificate fingerprints in the form of hashes of the encoded signed certificates. The full 
hash output for the specified algorithm shall be used to generate the fingerprint. A list generator shall check to insure 
that no two list entries match when creating a list. For an X509v3 [26] or X9.68 (currently being drafted) certificate the 
fingerprint hash shall be computed over the ASN.l encoded signed certificate object, first octet to last octet. For WTLS 
certificates the hash shall be computed over the signed WTLS certificate in network transmission format, first octet to 
last octet. 

The signature type and length shall be indicated by the administrator certificate, which shall be present on the device. If 
no administrator certificate is on the device or the signature does not verify the message shall be rejected. 

Upon receipt of a valid certificate configuration message the MExE device shall go through the trusted third party 
certificate list, computing fingerprints if they are not stored with the certificate, enabling or disabling each certificate 
according to the following conditions 
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• certificateAdvice is enable-all all TTP certificates shall be enabled 

• certificateAdvice is disable-all all TTP certificates shall be disabled 

• certificateAdvice is enable present list only enable all TTP certificates currently on device, do not enable any 
future certificates (this option allow the list to be fi-ozen at time of manufacture) until Administrator changes 

• certificateAdvice is enable-list if its fingerprint occurs in the CCM, it shall be enabled, otherwise it shall be 
disabled 

• certificateAdvice is disable-list if its fingerprint occurs in the CCM, it shall be disabled, otherwise it shall be 
enabled 

For future releases, the setting of fine grained permissions for each certificate is expected to be supported. 

An implementation shall keep track of the domain that authorised a given application. If a CCM message is received 
while MExE applications are currently running the implementation shall check to ensure any applications no longer in a 
trusted domain have their permissions re-configured appropriately and actions that are no longer permissible are 
terminated. 



8.13 Pre-verification of applications 



This is an optional feature added to eliminate the potentially excessive overhead of checking a signature each time an 
application is launched. 

To use this process the MExE device shall create a hash of the executable object (executable object fingerprint) as if 
checking the signature. This shall be stored in a protected verified application list, along with indication of the domain 
permissions for the application. The hash used shall be the same type as that used for signing the object. When 
launching an application or downloading an applet, the hash shall be performed as for when computing the signature. 
The verified application list shall then be checked; if the hash value is present and the entry has not expired then the 
application or applet may execute. If no list entry exists for this object, or the entry has expired, the process shall then 
proceed with the full signature verification. Note that the lists for applications and applets should be separate and that an 
implementation determines management policy for the lists (e.g., ageing policy, which entries to delete when trying to 
add a new entry to a full list etc.). One restriction imposed that shall be enforced is that the maximum number of uses for 
an entry before it is marked invalid is limited to some maximum value. 

In the event that a new CCM is received by the MExE MS, all verified application list entries shall be marked invalid 
unless some mechanism to determine the validity of an authorising certificate entry for each application is provided by 
the ME implementation. 

8.14 Certificate management 

Four type of certificates are provided for in MExE: 

• operator, 

• manufacturer, 

• trusted third party, and 

• Administrator of trusted third party domain. 

The manufacturer may load initial third party certificates on the device. Downloaded certificates shall be verified by an 
existing trusted certificate and placed in the domain defined by the root public key at the top of the verification chain for 
the downloaded certificate. Third party root public keys shall be stored in protected memory. All third party certificates 
shall be subject to restrictions imposed by valid certificate configuration messages. New third party root public keys 
may be downloaded as signed WAP or WWW content. The signature on the content shall be of the Administrator, 
Operator or Manufacturer. 

The manufacturer root public key is pre-loaded in protected memory on the device at manufacture time. It is 
recommended that the manufacturer should include a mechanism to re-key the device due to key compromise. See 
clause 8.5. The administrator root certificate shall be provided on the SIM if support for certificate storage on the SIM 
exists. For SIMs not having certificate storage the administrator root may be downloaded using the root download 
procedure described in section 8.9.2. 
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The actions that may be performed for a given certificate are: 

• addition, 

• deletion, 

• mark un-trusted (un-trusted certificates cannot be used to verify appHcations or other certificates. This process may 
be preferred to certificate deletion as there is a chance that the certificate may become trusted again in the near 
future), 

• mark trusted (marking as trusted is the process of allowing an untrusted certificate to come into use again), 

• modify fine grain access permissions (proposed as a future enhancement). 

The ability to perform these actions depend on the certificate type being modified as well as the access level of the entity 
performing the operation. Users may add a third party certificate as long as it is certified by an existing trusted 
certificate. 

Using a provisioned functionality, users may delete TTP certificates, but not TTP root public keys, nor any operator or 
manufacturer certificate. 

Table 5: Allowed certificate types in signed packages 



Signature on Package 


Allowed Certificate types in package 


Administrator 


TTP 


Manufacturer 


Administrator, Manufacturer, Operator, TTP 


Operator 


Administrator, Operator, TTP 



8.15 Provisioned mechanism for designating administrative 

responsibilities and adding trusted third parties in a IVIExE 
IVIS 

All applications in the TTP Domain are to be signed by a key which shall be verified back to a TTP root public key on 
the MExE MS. The TTP root public keys shall be managed (e.g. addition/deletion/mark trusted/mark untrusted/change 
fine grained access privileges) by an administrator that is designated by the owner of the MExE MS using the MExE 
administrator provisioning mechanism. A mechanism is required to be provided to enable the owner of the device to 
dynamically assign an administrator. The mechanism shall support the following cases: 

• the user is the owner 

• the owner is at a remote location. In this case the owner could be the operator, a service provider or a third party. 

• the owner of the MExE-SIM wants to be a temporary administrator. 

8.15.1 Determining the administrator of the IVIExE MS 

The administrator of the MExE MS shall be determined by the logical process shown in the flowchart in figure 9. 
During power-up the provisioned mechanism shall look for an administrator root public key that is stored on the ME. 

• Administrator root public key is absent 

if the administrator root public key is absent, then the user shall automatically become the administrator of the 
MExE MS 

• administrator root public key is present 

if an administrator root public key is present, this root public key shall be used for all remote administration 
authentication, implying that the owner of the administrator root public key is the administrator 
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Figure 9: MExE Release 98 administrator mechanism 

The rest of the mechanism is subsequently defined, however it is a future release implementation, see figure 10. This 
future enhanced administrator Mechanism shall be initiated after a power-up event is processed or when a MExE-SIM 
is detected. 

(The following subclauses assume that TTP certificates can be added using the MExE-SIM, however TTP certificates 
may be added using a non-SIM approach.) 



8.15.1.1 



Administrator of the IVIExE IVIS is the user 



If the administrator is the user, then a check shall be made to determine whether there is a MExE-SIM. If a MExE- 
SIM is present, then a check shall then be made to determine whether there is a certificate in the MExE-SIM. The 
enhanced administrator Mechanism shall allow the MExE MS to determine (via a format) what type of certificate is 
present: 

• certificate present - trusted third party (CP-TTP) 

a certificate present in the MExE-SIM shall be considered by the ME as a Trusted Third Party certificate, whilst 
that MExE-SIM is inserted in the ME. The user shall be queried to allow or disallow the certificate as a Trusted 
Third Party. 

• certificate present - administrator (CP- Admin) 

If a temporary certificate is present in the MExE-SIM, the user shall be queried whether to allow the certificate 
on the MExE-SIM to take temporary control of the trusted third party domain. By temporary control, it is meant 
that once the card is removed the administrator reverts back to the user administrator settings. The above 
mechanism implies that the previous configuration settings for the administrator shall be saved, so that they may 
be restored. If the user disallows the MExE-SIM certificate, the TTP Domain shall not be able to use any of the 
network capabilities in the trusted third party domain as identified in the network access section of the security 
table 3 

If a certificate is not present on the MExE-SIM and the administrator is the user, the user shall continue to be the 
administrator and may make use of all functionality. 



8.15.1.2 



Administrator of the IVIExE MS is not the user 



If the administrator is not the user, then a check is made to determine if there is a MExE-SIM. If a MExE-SIM is 
present, then a check is made to see if there is a certificate in the MExE-SIM. If a certificate is present in the MExE- 
SIM, then a comparison is made of the certificate's root public key on the MExE-SIM with the root public key on the 
ME for the following cases :- 
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• Case (a): they are the same 

• Case (b): they are not the same, but the ME certificate is cross-certified with the MExE-SIM certificate (a cross- 
certificate exists on the ME) 

• Case (c): they are not the same, but the ME certificate has a line of trust back to the MExE-SIM certificate 
domain 

• Case (d): they are not the same. 

If the owner of the pubHc key in the certificate on the MExE-SIM is to be a temporary administrator (CP- Admin), then 
in cases (a), (b) and (c), the temporary administrator shall be the owner of the CP- Admin root public key. In case (d), the 
TTP domain shall not use any of the network capabilities in the trusted third party domain as identified in the network 
access section of the security table 3. If the certificate is to be a TTP, then the certificate (CP-TTP) shall be verified with 
the CCM and based on the content and permissions of the CCM, the certificate shall be added to the TTP list or rejected. 




User is the \ 
administrator, U 
but TTP loses I 
network accessy 



Current \ 
administrator \ 
►I retained, but TTP 
domain loses / 
etwork access y 



Figure 10: Enhanced administrator mechanism 



8.15.2 Authorised CCM download mechanisms 

The download of trusted third party certificate lists by a remote administrator shall be performed by using a secure 
mechanism as defined below. The download mechanisms shall use HTTP over IP and/or the WAP Protocol. The URL 
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from which the CCM is downloaded shall be in the administrator certificate if the CCM was not downloaded with the 
Administrator certificate. The format for storing the URL information with the certificate shall be as shown in figure 1 1 : 



Urltype 


CharacterSet 


UrlLength 


URL 



Figure 11 : CCM Message URL storage format 

Urltype= one byte, enumerated {WAP (0), HTTP (1)}. All other values are reserved for future use 

CharacterSet = one byte, Internet Assigned Numbers Authority assigned character set. 

UrlLength = one byte unsigned integer, length of the URL in octets. 

The format for storing the URL information in the certificate shall be defined as part of the enhanced administrator 
mechanism. 

When the administrator is changed, then the CCM shall also be changed. If there is URL information with the certificate 
as described in figure 11, then the new CCM shall be obtained using the URL. If the Administrator certificate was 
downloaded in a JAR file, the CCM shall be obtained from the same JAR file. 
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